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Abstract

   This document defines a new Attribute-Value Pair (AVP) that allows
   L2TP Control Connection Endpoints (LCCEs) to advertise one or more
   Seamless Bidirectional Forwarding Detection (S-BFD) Discriminator
   values using the Layer Two Tunneling Protocol version 3 (L2TPv3).
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1.  Introduction

   [RFC7880] defines a simplified mechanism to use Bidirectional
   Forwarding Detection (BFD) [RFC5880], referred to as Seamless
   Bidirectional Forwarding Detection (S-BFD).  The S-BFD mechanism
   depends on network nodes knowing the BFD Discriminators that each
   node in the network has reserved for this purpose.  S-BFD requires
   the usage of unique discriminators within an administrative domain.
   The use of the Layer Two Tunneling Protocol version 3 (L2TPv3)
   [RFC3931] is one possible means of advertising these discriminators.

   This document specifies the encoding to be used when S-BFD
   Discriminators are advertised using L2TPv3.

1.1.  Terminology

   The reader is expected to be very familiar with the terminology and
   protocol constructs defined in S-BFD (see Section 2 of [RFC7880]) and
   L2TPv3 (see Section 1.3 of [RFC3931]).

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  S-BFD Target Discriminator ID AVP

   The S-BFD Target Discriminator Identifier (ID) Attribute Value Pair
   (AVP) is exchanged using the ICRQ (Incoming-Call-Request), ICRP
   (Incoming-Call-Reply), OCRQ (Outgoing-Call-Request), and OCRP
   (Outgoing-Call-Reply) control messages during session negotiation.
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2.1.  Encoding Format

   The S-BFD Target Discriminator ID AVP, Attribute Type 102, is an
   identifier used to advertise the S-BFD target discriminator(s)
   supported by an L2TP Control Connection Endpoint (LCCE) for the S-BFD
   reflector operation.  This AVP indicates that the advertiser
   implements an S-BFD reflector supporting the specified target
   discriminator(s) and is ready for S-BFD reflector operation.  The
   receiving LCCE MAY use this AVP if it wants to monitor connectivity
   to the advertising LCCE using S-BFD.

   The Attribute Value field for this AVP has the following format:

   S-BFD Target Discriminator ID (ICRQ, ICRP, OCRQ, OCRP):

                                          No. of octets
      +-----------------------------+
      | Discriminator Value(s)      |     4/Discriminator
      :                             :
      +-----------------------------+

   An LCCE MAY include the S-BFD Target Discriminator ID AVP
   advertisement in an L2TP control message (ICRQ, ICRP, OCRQ, OCRP)
   [RFC3931].  If the other LCCE does not wish to monitor connectivity
   using S-BFD, it MAY safely discard this AVP without affecting the
   rest of session negotiation.  While [RFC7880] concerns itself with
   the advertisement of only one discriminator unless the mapping of
   discriminators to entities is specified, the AVP encoding allows the
   specification of an arbitrary number of S-BFD Discriminators (at
   least one) for extensibility.

   When an LCCE uses the S-BFD Target Discriminator ID AVP
   advertisement, multiple S-BFD Discriminators MAY be included, and at
   least one S-BFD Discriminator MUST be included.  When one S-BFD
   Discriminator is advertised, such an S-BFD Discriminator is
   associated with the L2TPv3 session.  When multiple S-BFD
   Discriminators are advertised, how a given discriminator is mapped to
   a specific use case is out of scope for this document.
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   The S-BFD Target Discriminator ID AVP allows for advertising at least
   one S-BFD Discriminator value:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Discriminator 1                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Discriminator 2 (Optional)                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               ...                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Discriminator n (Optional)                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The M bit of the L2TP control message (ICRQ, ICRP, OCRQ, OCRP)
   [RFC3931] MUST NOT be set inside the S-BFD Target Discriminator
   ID AVP.

3.  IANA Considerations

   IANA maintains the "Control Message Attribute Value Pairs"
   sub-registry as per [RFC3438].  IANA has assigned the following value
   to the S-BFD Target Discriminator ID:

   Control Message Attribute Value Pairs

         Attribute
         Type          Description
         -----------   ------------------
         102           S-BFD Target Discriminator ID

4.  Security Considerations

   Security concerns for L2TP are addressed in [RFC3931].  The
   introduction of the S-BFD Target Discriminator ID AVP advertisement
   introduces no new security risks for L2TP.

   Advertising the S-BFD Discriminators makes it possible for attackers
   to initiate S-BFD sessions using the advertised information.  The
   vulnerabilities this poses and how to mitigate them are discussed in
   the Security Considerations section of [RFC7880].
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